GPSy now supports DGPS-IP servers through the Internet. John Sager has been kind enough to license us the code for his RTCM decoder, this allows you to monitor the output of the DGPS-IP server through the DGPS Data Monitor Window.

Some notes about DGPS-IP service:
 * Make sure your GPS unit is set to NMEA-Out / RTCM-In serial communications mode
 * DGPS corrections are sent out at the same serial BPS as the NMEA-in
 * Choose the DGPS server closest to you. There is one on the West Coast (California)
    and one on the East Coast (New Jersey). Hopefully more will be added in the future.
    If you'd like to host your own DGPS-IP server or for more information, see:
         http://www.wsrcc.com/wolfgang/gps/dgps-ip.html
 * DGPS-IP clients must report statistical data back to DGPS-IP servers. This includes
    a rough approximation of your current location. If you don't like this behavior,
    don't use the DGPS-IP service. The reports show up in the DGPS Data Monitor
    window as "R 45.0 -72.3 ..."  entries where 45.0/-72.3 are your approximate 
    coordinates. 
 * Just because you now have DGPS service doesn't mean that your GPS unit  
    can't be confused by multipath or erroneous signals and give you a false position.
    Caution, as always, is warranted and always double-check any navigational aid
    against known positions.
 * Other DGPS entries are from the RTCM decoder engine, below. We have not
    completed testing the code port, so please do not trust the RTCM decoder
    output in at-risk situations.

Karen Nakamura
Global Mapping Systems
http://www.gpsy.com



------------

Notes on the Printout Format of the RTCM Decoder.

Written by John Sager john.sager@btinternet.com
Copyright (C) 1999  John C Sager

History:
	v0.2	9th February 1999
	v0.1	5th February 1999


The RTCM decoder prints a legible representation of the input data.
The RTCM SC-104 specification is copyrighted, so I cannot
quote it - in fact, I have never read it! Most of the information
used to develop the decoder came from publication ITU-R M.823.
This is a specification of the data transmitted from LF DGPS
beacons in the 300kHz band. M.823 contains most of those parts of
RTCM SC-104 directly relevant to the air interface (there
are one or two annoying and vital omissions!). Information
about the serial interface format was gleaned from studying
the output of a beacon receiver test program made available on
Starlink's website.


Air Interface Data Format
-------------------------

This consists of a sequence of 30-bit words. The 24 most significant
bits are data and the six least significant bits are parity. The
parity algorithm used is the same as that used for GPS data
transmitted by the satellites.

Each DGPS message consists of two header words followed by zero or
more data words, depending upon message type.


Printout Format
---------------

In the printout each header is printed, followed by zero or more
lines containing the specific data for that message. The general
format is a line beginning with a capital letter, followed by a tab,
followed by the fields of the message separated by tabs, terminated by
a newline.

As well as data the decoder also prints decoder status messages,
as necessary.

Header (H)
----------

format:

H <message type> <reference station id> <modified z_count> <sequence no>
  <message length> <station health> [T <useful length>]

example:

H	9	687	337.2	4	5	0

<message type> is one of

1  full corrections - one message containing corrections for all satellites
   in view. This is not common.

3  reference station parameters - the position of the reference station
   GPS antenna.

4  datum - the datum to which the DGPS data is referred.

5  constellation health - information about the satellites the beacon can
   see.

6  null message - just a filler.

7  radio beacon almanac - information about this or other beacons.

9  subset corrections - a message containing corrections for only a subset
   of the satellites in view.

16 special message - a text message from the beacon operator.

<reference station id> is the id of the GPS reference receiver. The
LF transmitters also have (different) id numbers.

<modified z_count> is the reference time of the corrections in the
message in seconds within the current hour. Note that it is
the current hour in GPS time, which is several seconds ahead of
UTC (13 in 1999).

<sequence no> is a number which increments, modulo 8 for each
message transmitted.

<message length> is the number of words after the header that
comprise the message.

<station health> indicates the health of the beacon as a reference
source. 6 means the transmission is unmonitored. 7 means the
station is not working properly. Other values are defined by the
beacon operator.

If the message contains a parity error after the header but before
the end of the message, then the extra fields [T <useful length>]
are appended to indicate a truncated message.

example:

H	9	687	331.8	1	5	0	T	4

<useful length> indicates the number of useful words before the
parity error. Depending on the message type, useful information
may still be extracted.


Correction data (S)
-------------------

One or more of these follow the header for type 1 or type 9
messages.

format:

S <satellite> <udre> <iod> <modified z_count> <range error>
  <range error rate>

example:

S	7	0	199	331.8	-12.160	0.288

<satellite> is the PRN number of the satellite for which this is
correction data.

<udre> is User Differential Range Error with the following values:

0	1-sigma error <= 1m
1		"     <= 4m
2		"     <= 8m
3		"     >  8m

<iod> is Issue of Data, matching the IOD for the current ephemeris
of this satellite, as transmitted by the satellite.

<modified z_count> is just a copy of the same field from the header.

<range error> is the pseudorange error in metres for this satellite
as measured by the beacon reference receiver at the epoch indicated
by <modified z_count>

<range error rate> is the rate of change of pseudorange error in
metres/sec for this satellite as measured by the beacon reference
receiver at the epoch indicated by <modified z_count>. This is
used to calculate pseudorange errors at other epochs, if
required by the GPS receiver.


Reference Station Parameters (R)
--------------------------------

format:

R <X-coordinate> <Y-coordinate> <Z-coordinate>

example:

R	3746729.40	-5086.23	5144450.67

The coordinates are the position of the station, in metres to two
decimal places, in Earth Centred Earth Fixed coordinates.
These are usually referred to the WGS84 reference frame, but may
be referred to NAD83 in the US (essentially identical to WGS84 for
all except geodesists), or to some other reference frame in other
parts of the world.


Datum (D)
---------

format:

D <dgnss type> <dat> <datum name> [ <dx> <dy> <dz> ]

example (artificial):

D	GPS	0	ABC12	25.8	30.5	33.0

<dgnss type> is either GPS or GLONASS.

<dat> is 0 or 1 and indicates the sense of the offset shift given by
dx, dy, dz. dat = 0 means that the station coordinates (in the reference
message) are referred to a local datum and that adding dx, dy, dz to
that position will render it in GNSS coordinates (WGS84 for GPS). If
dat = 1 then the ref station position is in GNSS coordinates and adding
dx, dy, dz will give it referred to the local datum.

<datum name> is a standard name for the datum.

<dx> <dy> <dz> are offsets to convert from local datum to GNSS datum
or vice versa. These fields are optional.


Constellation Health (C)
------------------------

One or more of these follow the header for type 5 messages - one
for each satellite.

format:

C <sat> <iodl> <health> <cnr> <hlth en> <new data> <los warning>
  <time to unhealthy>

example:

C	29	0  0	53	0  0  0	 0

<sat> is the PRN number of the satellite.

<iodl> is 1 bit. 0 indicates that this information relates to the
satellite information in an accompanying type 1 or type 9 message.

<health> 0 indicates that the satellite is healthy. Any other value
indicates a problem (coding is not known)

<cnr> gives the carrier/noise ratio of the received signal in the
range 25 to 55 dB(Hz).

<health en> is 1 bit. If set to 1 it indicates that the satellite is
healthy even if the satellite navigation data says it is unhealthy.

<new data> is 1 bit. a 1 indicates that the IOD for this satellite will
soon be updated in type 1 or 9 messages.

<los warning> is 1 bit. a 1 indicates that the satellite will shortly
go unhealthy. The healthy time remaining is given in the <time to
unhealthy> field.


Radio Beacon Almanac (A)
------------------------

format:

A <latitude> <longitude> <range> <frequency> <health> <station id>
  <bitrate>

example:

A	54.1176	-0.0714	100	302.5	0	447	2

<latitude> and <longitude> give the position, in degrees, of the
LF transmitter antenna for the station for which this is an almanac.
North and East are positive.

<range> is the published range of the station in km.

<frequency> is the broadcast frequency in kHz.

<health> has the same meaning as in the header, but it indicates
the health of the station for which this is an almanac.

<station id> is the id of the transmitter. This is not the same
as the reference id in the header, the latter being the id of
the reference receiver. However I know of at least one station
that gets it wrong.

<bitrate> indicates the transmitted bitrate.


Special Message (T)
-------------------

format

T <text>

example:

T	THLS TRIAL SERVICE

<text> is just a text message sent by the beacon operator


Null (N)
--------

This just indicates a null message. There are no fields.


Decoder Status Messages (M)
---------------------------

format:

M <type>: <information>

examples:

M	state change: NO_SYNC -> WORD_SYNCING
M	sync_bit: 5

<type> indicates textually the type of message. There are
only the two types shown above.

<information>
For <type> = state change it describes the internal state
transition of the decoder when it changes state as a result
of the incoming data.

For <type> = sync_bit this indicates the bit position in the
serial data stream which is a word boundary.